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1.  INTRODUCTION 


“It  has  been  customary  to  think  of  operational  test  and  evaluation  in  terms  of 
physical  testing.  While  operational  testing  is  a  very  important  activity  ...  it  is 
emphasized  that  the  goal  is  operational  evaluation  and  that  physical  testing  is 
only  one  means  of  attaining  that  goal.  This  is  an  important  point,  since  it  is  often 
argued  that  operational  testing  must  await  production  of  an  adequate  number  of 
operationally-configured  systems;  and,  by  this  time,  it  is  too  late  to  use  the 
information  gathered  to  help  decide  whether  to  procure  the  new  system  or  even 
influence  in  any  significant  way  the  nature  of  the  system  procured.  ” 

The  Honorable  Thomas  Christe  -  Director,  DoD  Operational  Test  and  Evaluation 

1.1  Background 

In  recent  years,  the  Department  of  Defense  has  increased  use  of  modeling  and  simulation 
(M&S)  to  augment  and  speed  the  acquisition  of  new  defense  systems.  This  work  has  included 
recent  interest  in  using  M&S  to  test  new  systems  at  all  phases  of  the  design  life  cycle.  A  test 
plan  which  leverages  M&S  technologies  can  drastically  cut  down  on  design  cost  and  fielding 
schedules  by  identifying  shortcoming  and  performance  issues  early  on,  and  before  making 
significant  investments  in  time  or  money.  Likewise,  M&S  drastically  improves  our  ability  to 
conduct  integration  testing  of  new  and  existing  systems  in  large-scale  system  of  systems  (SOS) 
type  scenarios  where  total  system  testing  is  infeasible. 

However,  integration  of  M&S  techniques  into  current  test  doctrine  requires  detailed 
planning  and  standardization  in  order  to  ensure  accurate  validation  and  verification.  This  has 
prompted  the  urgent  need  for  robust  and  standardized  architectures  for  modeling,  simulation, 
stimulation,  instrumentation,  data  collection,  and  analyses.  As  the  Army  evolves  toward  a 


network-centric  force,  the  need  for  integrated  and  standard  test  M&S  enabled  test  environments 
becomes  even  more  important. 


1.2  United  States  Army  Operational  Test  Command  Modeling  Effort 

Beginning  in  the  summer  of  2002,  the  Army’s  Operation  Test  Command  (USAOTC) 
began  laying  the  groundwork  for  creation  of  a  new  generation  of  “sharing,  instrumentation, 
simulation,  and  stimulation  systems  (ISS)  [1]”  This  initiative  spawned  the  creation  of  the 
Operational  Test  Command  Analytical  Simulation  and  Instrumentation  Suite  (OASIS).  This 
family  of  systems  combines  the  models,  simulations,  instrumentation,  and  information 
technology  requirements  required  by  USAOTC  to  conduct  its  mission  -  planning  and  conducting 
independent  operational  testing  and  experiments  in  order  to  provide  essential  information  for  the 
decision  making  process. 

OASIS  is  a  federation  of  systems  focused  on  the  generation  of  operational  test  and 
evaluation  data.  Each  OTC  sponsored  test  may  involve  a  mix  of  OASIS  systems,  with  each 
system  performing  one  or  more  of  the  following  key  test  and  evaluation  functions: 

•  Modeling 

•  Simulation 

•  Stimulation 

•  Data  Collection 

•  Data  Transfer 

•  Data  Reduction 

•  Data  Analysis 
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2.  OUR  PROBLEM 


2.1  Air  Defense  Artillery  Simulation  (ADASIM) 

One  of  the  systems  being  developed  under  the  OASIS  umbrella  is  the  Air  Defense 
Artillery  Simulation  (ADASIM).  In  December  2003,  OTC  HQ  directed  that  Air  Defense 
Artillery  Test  Directorate  (ADATD)  develop  requirements  for  ADASIM  that  encompass  their 
needs  for  operational  testing  of  Army  systems  this  fiscal  year.  OTC  also  specified  that  the 
submission  be  documented  in  accordance  with  the  DoD  Architectural  Framework  (DoDAF). 
The  technical  director  of  OTC  wants  to  ensure  that  the  process  to  generate  these  requirements  is 
done  systematically  to  ensure  that  it  will  standup  to  budgetary  scrutiny. 

The  following  excerpt  from  an  ADATD  white  paper  [2]  describes  the  high  level 
operational  need  for  the  ADASIM: 


“The  ADASIM  will  play  a  critical  role  in  the  planning,  execution  and  analysis  of  future 
combat  system  (FCS)  equipped  units  of  action  (UA).  The  ADASIM  will  provide  the 
necessary  capabilities  for  utilizing  live,  virtual  and  constructive  simulation  in  a  real  time 
distributed  environment  to  provide  air  defense  scenarios,  threats,  systems,  platforms  and 
air  space  command  and  control  and  interoperability.  The  explicit  interdependency  of 
air/ground  operations  is  mentioned  nearly  continuously  in  the  ‘capabilities  required’ 
section  of  the  Operational  Requirements  Document  for  the  Future  Combat 
Systems. .  .This  migration  of  the  air  defense  battlefield  operating  system  from  specific 
ADA  systems  in  a  platform-centric  organization,  to  achieve  the  synergy  of  a  network¬ 
centric  organization  does  not  relieve  Army  Test  and  Evaluation  Command  (ATEC)  from 
its  responsibilities,  but  requires  modification  of  our  approaches  to  control  the  operational 
environment  for  test  and  evaluation  of  this  SOS.  ADASIM  will  support  test  and 
evaluation  at  the  system  level  as  well.  Most  conspicuous  is  the  multi-mission  radar 
(MMR).  ..ADASIM  will  be  able  to  emulate  this  sensor  function  in  the  early  stages  of 
SOS  testing,  and  stimulate  the  radar  for  later  testing  events.  Also,  all  the  FCS  platforms 
will  have  the  requirement,  per  ORD  3800,  to  use  the  alert  warning  information  to  resolve 
a  fire  control  solution  on  helicopters  and  UAVs  using  its  integral  fire  control  system  and 
conduct  LOS  CAFADS  engagements  within  the  capabilities  of  embedded  weapons.” 
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2.2  DoDAF 


The  DoDAF  is  a  standardized  framework  for  building  large-scale  systems  of  systems 
architectures.  The  framework  is  mandated  by  the  Information  Technology  Reform  Act  and  the 
Office  of  Management  and  Budget  (OMB)  Circular  A- 130.  The  purpose  of  the  framework  is  to 
standardize  the  creation  of  DoD  Enterprise  Architectures  in  order  to  increase  enterprise 
capability,  interoperability,  and  integration.  It  is  a  “product- focused”  method  for  standardizing 
architectures  and  provides  common,  pragmatic  guidelines  for  describing  architectures.  It  also 
provides  a  mechanism  for  examining  processes  and  system  alternatives  in  context  of  mission 
operations  and  information  requirements  [3].  These  efforts  will  ensure  that  existing  and  future 
DoD  systems  can  achieve  total  interoperability  and  hilly  meet  the  promises  heralded  by  the  shift 
toward  network-centric  warfare.  As  one  author  writes,  “Entities  that  are  not  interoperable  or 
have  limited  interoperability  will  not  have  access  to  all  available  information,  will  not  provide 
information  to  entities  that  may  need  it,  and  will  be  limited  in  ways  in  which  they  can  collaborate 
and  work  with  others.  [4]” 

The  DoDAF  provides  three  interrelated  views  to  represent  a  system’s  architecture  - 
system  views,  operational  views,  and  technical  views.  The  Operational  View  is  a  high  level 
description  of  the  tasks  and  activities,  operational  nodes  or  elements,  and  information  exchange 
requirements  between  nodes.  The  System  View  is  a  more  detailed  graphical  and  textual 
description  of  underlying  systems  within  the  said  architecture,  and  the  interconnections  used  to 
satisfy  operational  needs.  The  Technical  View  is  an  even  more  detailed  window  into  the 
minimal  set  of  rules  governing  the  arrangement,  interaction,  and  interdependence  of  system. 
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parts  or  elements  [3].  DoDAF  also  provides  for  an  All-View  which  captures  overarching  aspects 
of  all  three  views  into  a  concise  set  of  summary  documents. 


2.3  Project  Deliverables 


The  ADATD  enlisted  the  help  of  the  Operations  Research  Center  of  Excellence  (ORCEN) 
for  help  creating  the  initial  set  of  DoDAF  documents  for  ADASIM.  Specifically,  the  ADATD 
asked  the  ORCEN  to  develop  the  following  DoDAF  products  [5]: 


OV-1 

Operational  Concept  Description 

OV-2 

Node  Connectivity  Diagram 

OV-3 

Information  Exchange  Matrix 

OV-5 

Operational  Activity 

OV-6C 

Operational  Sequence  Diagram 

SV-1 

System  Interface  Description 

SV-7 

Service  Performance  Parameters  (for  items  not  covered  in  OV-3) 

AV-1 

Operational  and  Summary  Information 

AV-2 

Integrated  Dictionary 

This  technical  report  is  a  result  of  our  efforts  to  complete  these  tasks.  During  our  initial 

research  into  the  requirements  for  constructing  the  DoDAF  documents,  we  discovered  that  the 

DoDAF  is  largely  a  product  based  framework.  As  one  panel  described  it, 

“The  current  DoDAF  is  representation  oriented,  and  does  not  impose  or  recommend  a 
process  for  architecture  development.  Such  a  process  can  be  quite  sophisticated  and  can 
differ  across  contractors  and  vendors.  Guidance  and  expertise  can  prevent  the  developer 
from  making  mistakes  others  have  already  made. .  .The  is  no  clear  set  of  criteria  to 
determine  what  constitutes  ‘acceptable  and  good’  versus  ‘unacceptable  and  poor’  for 
individual  view  products  or  the  set  of  products  developed  [6]” 


We  offer  that  much  of  the  aforementioned  criticism  stems  from  the  simple  fact  that  the 
DoDAF  is  a  framework.  Frameworks  are  intentionally  vague  to  allow  for  sufficient  flexibility  in 
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implementing  designs.  However,  this  flexibility  must  be  balanced  against  the  intended 
standardization  goal  of  DoDAF.  We  believe  that  our  approach,  which  employs  a  systems 
engineering  methodology  to  develop  the  DoDAF  documents,  provides  such  balance. 

3.  OUR  APPROACH 

3.1  The  Systems  Engineering  Management  Process  (SEMP) 

In  an  effort  to  inject  process  into  the  development  of  the  desired  DODAF  products,  we 
must  first  adopt  an  effective  systems  engineering  methodology.  A  systems  engineering 
methodology  represents  a  systematic  way  of  decomposing  a  high-level  need  into  a  set  of  well 
defined  requirements  and  accompanying  designs  to  satisfy  these  requirements.  Several 
prominent  methodologies  abound  within  the  systems  engineering  discipline.  The  Design 
Methods  Comparison  Project,  sponsored  by  the  International  Council  on  Systems  Engineering 
(INCOSE)  offers  a  comprehensive  review  of  contemporary  methodologies  used  in  practice  [7]. 
Some  of  the  more  well-known  methodologies  discussed  in  this  project  include:  the  Capability 
Maturity  Model®  Integration  (CMMI),  MIL-STD-499B,  EIA/IS  Standard  632,  and  IEEE 
Standard  1220.  Each  of  these  methodologies  addresses  seven  key  system  engineering  activities- 
State  the  Problem,  Investigate  Alternatives,  Model,  Integrate,  Launch,  Assess  and  Re-evaluate 
(SIMILAR)  [7], 

We  will  select  and  apply  a  systems  engineering  methodology  known  as  the  Systems 
Engineering  and  Management  Process  (SEMP)  in  order  to  address  development  of  the  ADASIM 
architecture.  This  process,  developed  at  the  United  States  Military  Academy,  helps  engineers 
systematically  design  large-scale,  complex  systems  to  address  problems  [8],  The  SEMP 
methodology  satisfies  the  seven  fundamental  activities  required  in  an  effective  systems 
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engineering  approach  as  defined  by  [7],  and  has  been  applied  to  hundreds  of  civil  and  military 
applications.  We  will  first  introduce  the  SEMP  in  general  terms  before  applying  it  to  the 
ADASIM  design  problem.  We  will  then  demonstrate  its  partial  application  to  the  ADASIM,  and 
demonstrate  how  one  can  use  a  portion  of  the  process  to  methodically  produce  the  desired 
DoDAF  products  for  ADASIM  or  any  other  systems  engineering  process. 

The  SEMP,  shown  in  Figure  1,  is  a  four  phase  iterative  process  involving  nine  unique 
steps.  A  descriptive  scenario  specifies  the  current  state  of  a  given  system  or  situation.  A 
normative  scenario  describes  the  desired  state  of  the  system  or  situation.  The  difference  between 
these  two  scenarios  is  the  problem.  In  the  case  of  ADASIM,  the  descriptive  scenario  is  the 
current  set  of  ADATC  modeling  and  simulation  tools.  The  normative  scenario  is  fully  deployed 
ADASIM  system  that  can  serve  within  the  OASIS  framework. 

The  engineering  process  on  the  inside  of  the  diagram  is  an  iterative  process  we  execute  to 
arrive  at  the  normative  scenario.  The  first  phase  of  the  process,  the  problem  definition  phase, 
involves  two  steps  -  needs  analysis  and  value  system  design.  The  needs  analysis  step  entails 
understanding,  redefining,  and  formalizing  the  problem  definition.  The  value  system  design  step 
involves  constructing  an  upfront  value  system  that  fits  within  the  context  of  the  problem 
definition  and  can  later  help  ideate  and  evaluate  potential  alternatives. 

The  second  phase  of  the  SEMP  is  the  design  and  analysis  phase  which  is  broken  down 
into  alternatives  generation  and  modeling  and  analysis  steps.  Alternatives  generation  involves 
creating  potential  alternatives  to  address  the  needs  defined  in  the  needs  analysis  step.  The 
modeling  and  analysis  step  is  concerned  with  identifying  the  feasibility  of  alternatives,  as  well  as 
optimizing  and  measuring  each  alternative. 
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The  third  phase  of  the  SEMP  is  the  decision  making  phase  which  is  broken  down  into  the 
alternative  scoring  and  decision  steps.  In  the  alternative  scoring  step,  we  use  the  value  system 
from  the  problem  definition  phase  to  calculate  a  “total  value  score”  for  each  alternative.  In  the 
decision  step,  we  use  these  value  scores  to  recommend  one  alternative  to  the  decision  maker. 
This  decision  includes  a  detailed  sensitive  and  cost- value  analysis. 

The  final  phase,  implementation,  involves  the  three  remaining  steps  of  the  process  -  plan 
of  action,  execution,  and  assessment  and  control.  The  plan  of  action  represents  the  project  plan 
detailing  how  we  will  implement  our  winning  alterative.  Execution  involves  actually  employing 
hardware,  software,  and  other  resources  to  create  the  alternative.  Assessment  and  control 
involves  observing  and  controlling  the  system  over  its  lifetime. 


Descriptive 
Scenario 
Current  Status: 
What  Is? 


Figure  1  -  The  Systems  Engineering  and  Management  Process 
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It  is  important  to  note  the  iterative  nature  of  the  SEMP  and  its  four  major  phases.  The 
iteration  at  each  phase  represents  the  continual  processing  and  prototyping  that  is  conducted  at 
each  phase  until  certain  conditions  are  set  to  commence  the  next  phase.  The  iterative  nature  of 
the  SEMP  prompts  us  to  re-execute  when  the  descriptive  scenario  no  longer  matches  the 
normative  scenario. 

3.2  SEMP  Implementation 

We  will  now  turn  to  implementation  of  the  SEMP  process  to  address  the  design  of  the 
ADASIM.  Because  the  ADASIM  is  an  architecture,  and  not  an  actual  software  or  hardware 
system,  we  will  only  execute  the  first  step  of  this  process  -  Problem  Definition.  However,  it  is 
important  to  point  out  that  the  remaining  steps  of  the  SEMP  should  be  applied  to  an  actual 
implementation  of  the  ADASIM. 

While  executing  the  first  phase  of  the  SEMP,  we  will  highlight  a  series  of  techniques  and 
tools  that  aid  our  analysis.  In  doing  so,  we  will  continue  to  demonstrate  how  the  SEMP  can 
serve  as  a  straight-forward  and  analytical  process  for  generating  DoDAF  required 
documentation.  In  the  interest  of  brevity,  we  have  moved  the  DoDAF  products  to  the  appendices 
and  will  not  include  them  directly  in  our  discussion  of  the  SEMP  implementation. 

3.2.1  Problem  Definition 

We  begin  the  application  of  the  SEMP  to  the  ADASIM  architecture  at  the  problem 
definition  phase.  The  problem  definition  phase  helps  define  the  descriptive  and  normative 
scenarios,  and  establishes  high  level  requirements  for  our  design.  It  is  also  the  genesis  of  our 
first  DoDAF  document  -  the  AV-1  (Overall  and  Summary  Information).  As  we  continue  the 
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problem  definition  step,  we  will  gradually  build  and  expand  the  AV-1 .  Appendix  A  contains  the 
resultant  AV-1. 

3.2. 1.1  Needs  Analysis 

The  problem  definition  phase  starts  with  the  needs  analysis  step.  Needs  analysis  begins 
with  receipt  of  the  Initial  Problem  Statement  (IPS).  This  is  a  rough  description  of  the  problem 
provided  by  the  chief  decision  maker.  In  the  case  of  ADASIM,  the  Air  Defense  Artillery  Test 
Directorate  provided  the  following  initial  problem  statement  [5]: 


“Apply  a  systems  engineering  process  focusing  on  the  functional  analysis  of  core  Air 
defense  test  Directorate  (ADATD)  mission  to  produce  an  architectural  framework  for  Air 
Defense  Artillery  simulation  that  supports  OASIS.  The  purpose  of  the  system  is  to 
provide  the  ability  to  evaluate  Air  Defense  Artillery  systems  as  part  of  the  Operational 
Test  Command  Analytical  Simulation  and  Instrumental  Suite  (OASIS).  Produce 
architectural  design  and  ancillary  perquisite  documents  in  accordance  with  Department 
of  Defense  Architectural  Framework  (DoDAF).  ” 


The  purpose  of  the  ADASIM,  contained  in  the  above  Initial  problem  Statement,  is  added 
to  the  AV-1 .  Any  other  high  level  requirements  contained  within  an  initial  problem  statement 
should  also  be  added  to  the  AV-1. 


3.2.1. 1.1  Facts  and  Assumptions 


Our  task  in  the  Needs  Analysis  step  is  to  identify  salient  facts  and  assumptions.  These 
facts  and  assumptions  serve  to  scope  and  bound  our  problem.  This  information  helps  populate 
the  AV-1,  and  also  provides  support  for  the  creation  of  other  DoDAF  documents.  Additionally, 
any  terminology  or  other  domain  knowledge  (objects,  entities,  actors,  messages,  etc)  is  added  to 
the  AV-2  (Integrated  Dictionary). 


13 


Interoperability.  The  OASIS  M&S  federates  [i.e.  ADASIM]  shall  be  designed  to  work  in 
conjunction  with  the  DoD  Global  Information  Grid  (GIG),  the  RDECOM  Modeling 
Architecture  for  Technology  and  Research  Experimentation  (MATREX)  program,  the 
Future  Combat  System  (FCS)  System  of  Systems  Integration  Laboratory  (SoSIL),  other 
federates,  and  with  the  M&S  used  for  battle  simulation.  This  requirement  is  a  time- 
phased  requirement.  Initial  interoperability  shall  be  achieved  through  compliance  with 
the  Department  of  Defense  (DoD)  Joint  Technical  Architecture  (JTA),  Department  of  the 
Army  (DA)  Joint  Technical  Architecture  -  Army,  (JTA-A),  DoD  Global  Information 
Grid  (GIG),  Defense  Information  Infrastructure  Common  Operating  Environment  (DII 
COE)  and  the  High-Level  Architecture  (HLA)  standards.  Objective  interoperability 
standards  shall  be  achieved  through  compliance  with  the  DoD  Architecture  Framework 
(DoDAF),  Network  Centric  Enterprise  Services  (NCES)  Standard,  the  Test  and  Training 
Enabling  Architecture  (TENA),  and  eventually  the  Joint  Defense  Engineering  Plant 
(JDEP)  standards.  Additionally,  OASIS  federates  shall  be  capable  of  communicating  over 
various  means,  to  include  wide  area  networks,  local  area  networks,  tactical  radios, 
satellite  transmission,  and  the  Defense  Research  Engineering  Network  (DREN),  as 
appropriate  for  each  use  [9], 

Scalability.  The  OASIS  federates  (i.e.  ADASIM)shall  be  capable  of  performing  their 
functions  in  test  environments  from  individual  systems  up  to  a  multi-national  coalition 
Corps  and  above  level  exercise.  This  includes  aggregation  and  de-aggregation 
capabilities  where  appropriate.  OASIS  Components  shall  be  capable  of  simulating  and 
stimulating  operational  environments  incorporating  single  and  multiple  networks,  and 
single  to  multiple  Battlefield  Operating  Systems  (BOS).  OASIS  federates  will  be 
scalable  for  use  in  developmental  testing  and  training  applications  in  addition  to  their 
primary  role  of  supporting  operational  testing  [9]. 

Operational  Realism.  OASIS  (and  ADASIM)  shall  be  capable  of  incorporating 
operational  realism  effects  in  the  simulated  battlefield,  and  capturing  operational 
performance  data  as  a  result  of  these  effects.  These  include  terrain  effects  on 
communications  and  mobility,  weather  effects,  other  communications  effects,  non¬ 
military  entities,  and  the  fidelity  of  entity  states.  OASIS  identifies  voids  or  holes 
impacting  the  ability  to  create  operational  realism  and  works  to  develop  models, 
simulations,  and  instrumentation  necessary  to  fill  those  voids.  Examples  of  these  voids 
include  a  logistics  driver,  electronic  attack  (synthetic  jamming  /  computer  network 
operations),  non-military  models  (refugees,  vehicle  traffic,  cell  phones,  emergency 
broadcast  networks,  etc.)  and  many  threat  situations  to  cite  a  few  examples.  When 
equipped  with  appropriate  scenarios,  databases,  and  simulation  interfaces,  OASIS 
Components  can  also  provide  support  to  development  and  integration  testing,  training, 
exercises,  and  military  operations  planning  and  analysis  [9]. 

Standards  Compliance.  OASIS  Components  (i.e.  ADASIM)shall  be  developed  in 
accordance  with  applicable  DoD  and  IEEE  standards  to  facilitate  interoperability  and 
compatibility  of  models  and  instrumentation  for  distributed  test  and  evaluation  [9]. 


•  Functionality.  OASIS  Components  (i.e.  ADASIM)shall  provide  all  functionality 
necessary  to  perform  the  operational  tests  and  evaluations  of  the  FCS  and  Future  Force, 
including  lethality,  C4ISR,  Battle  Command,  Maneuver  Support,  Deployability  / 
Transportability,  Tactical  Maneuver  /  Mobility,  Survivability,  Sustainability, 
Interoperability,  and  Training  [9]. 

•  Compatibility.  OASIS  Tools  (i.e.  ADASIM)shall  be  compatible  with  other  standards 
conformant  models  and  instrumentation  [9]. 

•  Data  Management.  OASIS  Tools  (i.e.  ADASIM)shall  provide  the  capability  for  both 
centralized  and  de-centralized  data  collection,  reduction,  aggregation,  analysis, 
evaluation,  and  presentation  [9]. 

•  Communications.  OASIS  Components  (i.e.  ADASIM)shall  support  multiple 
simultaneous  communications  interfaces  such  as  Wide  Area  Networks,  Local  Area 
Networks,  Satellite,  and  tactical  radio  over  a  variety  of  transmission  media  for  both  voice 
and  data  [9]. 

•  Information  Security.  All  OASIS  Components  (i.e.  ADASIM)shall  be  tested  and 
approved  to  process  a  variety  of  information  ranging  from  Unclassified  through  Top 
Secret  Special  Compartmented  Intelligence  using  either  the  DITSCAP  or  DODIIS 
process.  The  Certification  and  Accreditation  (C&A)  requirements  for  each  OASIS 
component  shall  be  determined  by  the  security  classification  of  the  information  that 
component  processes.  The  developer  of  each  component  must  support  and  execute  this 
C&A  testing.  Each  federation  of  OASIS  Components  must  be  tested  and  approved  to 
process  classified  information  at  the  level  specified.  OASIS  tools  shall  be  managed 
through  a  centralized  OASIS  Configuration  Management  organization  and  process  [9]. 

•  Distributed.  OASIS  Components  (i.e.  ADASIM)shall  perform  and  support  distributed 
modeling  and  simulation.  The  operational  elements  of  interoperability,  standards 
compliance,  compatability,  communications,  and  information  security  enable  OASIS 
Components  to  participate  in  and  utilize  distributed  modeling  and  simulation.  [9] 

•  ADASIM  will  support  test  and  evaluation  of  the  multi-mission  radar  (MMR).  This 
system  is  the  primary  source  of  detecting  air  threats  manned  and  unmanned.  ADASIM 
will  be  able  to  emulate  this  sensor  function  in  the  early  stages  of  SOS  testing,  and 
stimulate  the  radar  for  later  testing  events  [2]. 

•  ADASIM  will  support  the  testing  of  FCS  systems  [2]. 

•  ADASIM  will  support  the  testing  FCS  systems  that  use  alert  warning  information  to 
resolve  a  fire  control  solution  on  helicopters  and  UAVs  using  integral  fire  control  system 
[2], 
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•  ADASIM  will  support  the  testing  of  FCS  systems  as  they  conduct  LOS  CAFADS 
engagements  within  the  capabilities  of  embedded  weapons  [2]. 

Assumptions: 

•  Implementing  simulation  designs  employing  the  ADASIM  architecture  will  be  based  on  a 
discrete  event  simulation  paradigm.  A  discrete  event  simulation  models  a  system  as  it 
evolves  over  time  where  system  entities  change  instantaneously  at  discrete  points  in  time 
[10].  This  assumption  is  critical  in  our  suggested  OV-5  and  OV6c  documents. 

3.2.1. 1.2  Stakeholder  Analysis 

We  now  turn  to  the  next  task  in  the  needs  analysis  step  -  Stakeholder  Analysis.  This 
important  task  gathers  stakeholder  information  (contact  and  background  information)  and 
requirements  for  the  ADASIM,  and  ties  these  requirements  into  the  overall  simulation 
architecture.  These  requirements  are  gathered  by  identifying  the  needs,  wants,  and  desires  of 
each  stakeholder.  This  process  defines  the  specific  objects,  definitions,  and  functions  that 
populate  the  following  views:  AV-1,  AV-2,  OV-1,  0-5,  and  0V-6a. 

The  following  sections  identify  the  main  stakeholders  in  the  ADASIM.  These 
stakeholders  are  categorized  by  one  or  more  of  five  basic  stakeholder  types  -  client,  analyst, 
user,  decision  maker,  or  sponsor.  A  client  stakeholder  represents  the  primary  manager  of  the 
desired  system.  The  decision  maker,  often  the  same  person  or  agency  as  the  client,  represents 
the  agency  that  will  approve  the  final  design.  The  analyst  and  user  stakeholder  types  represent 
specialized  and  generic  users  of  the  resultant  design.  The  sponsor  represents  the  primary 
financier  of  the  system.  Canvassing  each  of  the  stakeholder  types  helps  ensure  an  equal 
representation  of  the  diverse  stakeholders  that  might  be  curators  in  any  systems  engineering 
design  problem. 
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Air  Defense  Artillery  Test  Directorate  (Client/Decision  Maker/Sponsor)  -  ADATD  is  the 
primary  operational  testing  organization  for  air  and  missile  defense  weapon  systems.  Current  and 
recent  tests  include  PATRIOT  PAC  III,  Forward  Area  Air  Defense  (FAAD)  C3I,  and  the 
Sentinel  ETRAC  radar.  This  directorate  is  unique  in  the  span  of  the  horizontal  (Army  Battle 
Command  System)  and  vertical  (joint  links)  integration  of  the  command  and  control  integral  to 
these  systems.  Additionally,  operational  testing  of  acquisition  programs  under  the  oversight  of 
the  highest  level  require  careful  consideration  of  blending  live,  virtual,  and  constructive 
simulation  to  produce  a  realistic  and  certifiable  operational  scenario.  The  result  of  this  effort 

must  produce  requirements  that  support  efforts  for  test  planning,  execution  (including  integration 

) 

with  real-time  instrumentation  systems),  analysis  and  control. 

OASIS  Users/Potential  implementing  systems  (Users).  ADASIM  users,  like  any  OASIS  user, 
desire  a  fully  interoperable  simulation  architecture  that  interfaces  with  any  other  OASIS  federate. 
They  desire  scalability,  extensibility,  operational  realism,  standards  compliance,  functionality, 
compatibility,  data  management,  effective  communications,  and  information  security. 

PTC  Analysts  (Analyst! .  OTC  Analysts  desire  the  same  set  of  requirements  as  OASIS  users. 
Additionally,  the  ADASIM  must  meet  all  requirements  specified  for  Army  Test  and  Evaluation 
activities. 

3.2.1.1.3  Affinity  Diagramming 

At  this  point  in  our  analysis,  our  analysis  has  generated  a  plethora  of  information  facts, 
assumptions,  -  stakeholder  requirements,  domain  objects,  and  domain  terminology.  In  order  to 
better  understand  and  organize  this  information,  we  conduct  an  affinity  diagramming  process.  In 
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this  exercise,  we  place  keywords  from  these  disparate  ideas,  objects,  and  requirements  into  an 
unordered  set  U.  We  then  arrange  similar  sounding  elements  of  U  into  unidentified  subsets  uj, 

U2,  ••• >  W/.  Duplicate  and  meaningless  objects  are  eliminated  from  these  sets.  We  then  analyze 
each  unordered  set and  attempt  to  identify  what  each  member  of  the  subset  has  in  common 
with  its  siblings.  Once  this  is  established,  we  assign  a  meaningful  title  to  each  subset We 
then  document  and  record  each  member  of  each  subset  w,  and  describe  the  subset  headings. 

This  seemingly  trivial  exercise  serves  several  key  functions.  First,  it  organizes  and  filters 
our  knowledge  and  understanding  of  the  problem  domain.  Second,  it  identifies  critical  system 
components  and  functions  that  will  populate  the  System  Views  (SV)  and  Operational  Views 
(OV)  of  our  DoDAF  documentation.  Third,  it  pairs  stakeholder  requirements  with  system 
functions. 

Because  of  the  large  volume  of  needs,  wants,  desires,  functions,  and  objects  identified  in 
earlier  phases  of  the  SEMP,  we  first  subdivided  our  entities  into  two  obvious  sub-groups  - 
components  and  functions.  This  was  largely  accomplished  by  identifying  terms  and 
requirements  that  appear  as  verbs.  When  then  executed  the  affinity  diagram  process  on  each 
subgroup,  and  arrived  at  the  ordered  and  identified  sub-groupings. 

3.2.1.1.4  Systems  Decomposition 

We  next  turn  to  conducting  a  detailed  systems  decomposition  of  the  desired  end  system. 
A  complete  system  decomposition  generates  a  hierarchical,  functional,  and  component  view  of 
the  proposed  ADASIM  architecture.  This  process  will  lead  directly  to  the  development  of  the 
SV-1  and  SV-2  Views. 
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Hierarchical  Decomposition  -  Scope  and  Bound 


In  order  to  generate  a  hierarchical  view  of  the  ADASIM,  we  will  arrange  the  components 
identified  in  our  affinity  diagramming  process  into  super,  lateral,  and  sub  systems  components  of 
the  ADASIM.  Super-system  components  are  those  components  outside  the  boundary  of  the 
ADASIM  that  encapsulate  the  functionality  of  ADASIM.  Lateral  components  represent 
components  outside  the  boundary  that  interact  with  but  don’t  include  the  ADASIM.  Sub¬ 
components  represent  components  within  the  ADASIM  boundary  (within  ADASIM  control).  It 
is  important  to  recognize  that  several  components  identified  in  our  affinity  diagramming  might 
appear  as  both  a  lateral  and  sub  component.  For  example,  a  friendly  force  entity  such  as  a 
missile  platform,  might  be  simulated  within  ADASIM,  simulated  in  a  networked  simulation  in 
the  same  federation,  or  both.  Finally,  we’ve  only  included  the  main  headings  of  our  affinity 
diagramming  process  in  the  interest  of  clarity. 

Super  System  Components 
OASIS 

Lateral  System  Components 

Command  and  Control  Objects 
External  Simulations 
Env.  Chamber 

Live,  Virtual,  or  HITL  Sensors 

Data  Collection  Components 

Simulation  Network 

Live,  Virtual,  or  HITL  Threat  Entities 

Neutral  Objects  of  Interest 

Interfaces 

Data  Storage  Components 
Motion  Stimulator 
Vibration  Table 
Friendly  Force  Units 
Friendly  Air  Objects  of  Interest 
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Friendly  Ground  Objects  of  Interest 
Signal  Injection/Projection 
Shock  Test 

Data  Analysis  Components 
Friendly  ADA  Weapons  Systems 
Friendly  Force  Units 
Signatures 
Testers  Node 

Sub-Svstem  Components 

ADASIM  Simulation  Control 

ADASIM  Internal  Friendly  Ground  Objects  of  Interest 

ADASIM  Internal  Friendly  Air  Objects  of  Interest 

ADASIM  Data  Management 

ADASIM  Internal  Command  and  Control  Objects 

ADASIM  Data  Collection 

ADASIM  Data  Storage 

ADASIM  Data  Analysis 

ADASIM  Internal  Live,  Virtual,  or  HITL  Threat  Entities 
ADASIM  Internal  Neutral  Objects  of  Interest 
ADASIM  Internal  Friendly  ADA  Weapons  Systems 
ADASIM  Internal  Friendly  Force  Units 
ADASIM  Node 
Threats  Node 

Command  and  Control  Node 
External  Sensors  Node 
Support  Node 
Fires/Sensor  Node 


In  an  effort  to  prime  and  seed  our  OV-1  and  OV-2  DoDAF  documents,  we  will 
arrange  this  hierarchy  in  a  Context  Diagram  [11].  A  context  diagram  arranges  the  components 
from  our  affinity  diagramming  process  into  a  logical  hierarchy.  Figure  2  shows  the  resultant 


context  diagram. 


Figure  2  -  ADASIM  Context  Diagram 
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The  hierarchical  decomposition  described  above  scopes  and  bounds  the  ADASIM.  This 
scoping  and  bounding  is  represented  in  the  context  diagram  above  by  the  circle  titled  ADASIM. 
This  circle  represents  the  ADASIM ’s  system  boundary,  or  the  span  of  control  and  responsibility 
garnered  by  the  ADASIM  architecture.  Entities  outside  this  boundary  will  be  outside  the  scope 
of  the  ADASIM,  but  might  interact  with  our  architecture. 

The  hierarchical  decomposition  also  helps  prime  our  OV-1  and  OV-2  documents.  By 
following  the  general  structure  of  the  context  diagram,  we  can  easily  arrange  the  relevant  super, 
lateral,  and  sub-system  components  of  the  ADASIM  architecture  into  meaningful  operational 
views.  These  view  are  listed  in  Appendix  C  and  D. 

3.2.1. 1.5  Functional  Analysis 

After  completing  our  system  decomposition,  we  next  turn  to  the  task  of  completing  a 
functional  analysis  of  the  ADASIM  architecture.  The  functional  analysis  decomposes  the  system 
into  its  key  functions,  then  examines  how  these  functions  interact  to  satisfy  the  stakeholder 
needs.  These  functions  and  their  associated  interaction  will  form  the  backbone  of  the  SV 
documents  within  the  DoDAF. 

The  functional  analysis  process  involves  three  steps  -  a  functional  decomposition, 
construction  of  a  functional  hierarchy,  and  functional  flow  analysis. 

Functional  Decomposition 

A  functional  decomposition  of  the  ADASIM  seeks  to  identify  all  relevant  and  salient 
functions  that  the  desired  system  should  perform.  This  process  is  straight  forward  given  the 
results  of  the  affinity  diagramming  process.  The  affinity  diagramming  process  captures  the 
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desired  functions  of  the  stakeholders,  as  well  as  the  objects  and  entities  we  used  earlier  in  the 

system  decomposition.  We  simply  revisit  our  affinity  diagram  product,  and  extract  functional 

concepts.  The  important  high  level  functions  are  shown  here: 

Adjust  Air  Defense 
Provide  Air  Defense  Coverage 
Engage  Threat 
Control  Airspace 

Provide  Air  Defense  Command  Control 
Defense 

Sustain  Air  Defense 
Control  Simulation 

Functional  Hierarchy 


The  next  step  in  the  functional  analysis  of  the  ADASIM  is  the  construction  of  a 
functional  hierarchy.  The  functional  hierarchy  arranges  the  functions  in  our  functional 
decomposition  into  parent-child  relationships.  These  relationships  help  use  better  understand  the 
interaction  of  various  functions  within  ADASIM.  Figure  3  shows  the  functional  hierarchy. 
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Figure  3  -  ADASIM  Functional  Hierarchy 

Functional  Flow  Analysis 

Functional  Flow  Analysis  is  the  final  task  within  functional  analysis,  and  involves 
arranging  functions  into  the  sequence  in  which  they  occur  within  the  system.  This  arrangement 
serves  the  exact  purpose  of  the  OV-5  and  OV-6a  views  of  the  DoDAF.  Given  the  fact  that  we 
have  already  identified  our  functions  in  functional  decomposition,  and  arranged  them  into  a 
functional  hierarchy,  the  task  of  building  our  OV-5  and  OV-6a  documents  is  much  easier. 

At  this  point,  we  must  remember  we  are  defining  a  simulation  architecture.  Many  of  the 
function  titles  identified  in  our  functional  decomposition  suggest  the  functionality  of  actual 
operating  weapons  systems,  not  simulation  entities  or  systems  under  test.  Because  we  are 
assuming  a  discrete  event  simulation,  such  real-world  events  as  “Engage  Threat”  will  serve  as 


simulation  events  executed  by  real  or  simulated  ADASIM  or  OASIS  components.  The 
simulation  will  control  and  coordinate  these  events  to  support  a  particular  test.  In  order  to 
reinforce  this  focus  on  the  simulation,  we  will  rename  each  of  our  top  level  functions  in  this  vein: 

Adjust  Air  Defense  =>  Execute  Air  Defense  Coverage  Adjustment  Event 

Provide  Air  Defense  Coverage  =>  Execute  Take  Active  Air  Defense  Measures  Event 

Engage  Threat  =>  Execute  Engage  Target  Event 

Control  Airspace  =>  Execute  Airspace  Planning  and  Coordination  Event 

Provide  Air  Defense  Command  Control  =>  Execute  Air  Defense  Command  and  Control 

Event 

Sustain  Air  Defense  =>  Execute  Sustain  Air  Defense  Measures  Event 
Control  Simulation 

Figure  4  shows  the  top  level  functional  flow  for  the  simulation.  The  OV-5  and  OV-6a 
views  at  Appendix  E  and  F  provide  a  detailed  view  of  the  complete  ADASIM  functional  flow. 

3.3  Future  Directions 

Because  we  are  designing  an  architecture  that  will  serve  as  guidance  for  other  designs, 
we  pause  implementation  of  the  SEMP  at  this  point.  The  remaining  steps  of  the  SEMP  focus  on 
a  specific  simulation  design,  where  the  ADASIM  is  a  meta-design  used  to  guide  the  design 
process  of  an  eventual  simulation.  Continuing  the  SEMP,  without  a  particular  physical 
simulation  design  in  mind,  would  be  a  premature  exercise. 
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Figure  4  -  ADASIM  Top-level  Functional  Flow 
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However,  it  is  important  to  highlight  that  an  actual  simulation  design  could  initiate  the 
SEMP  from  this  point,  and  leverage  the  efforts  of  the  needs  analysis.  The  needs  analysis 
products  produced  in  this  documents,  with  the  accompanying  ADASIM  DoDAF  documentation, 
will  help  standardize  and  accelerate  the  design  process.  In  fact,  that  is  the  very  purpose  of  the 
ADASIM  architectural  framework. 

We  recommend  that  any  design  efforts  to  implement  an  actual  ADASIM-based 
simulation  should  begin  by  defining  a  Revised  Problem  Statement.  The  Revised  Problem 
Statement  is  the  final  task  in  the  Needs  Analysis  step  of  the  SEMP.  The  Revised  Problem 
Statement  is  used  to  refine  the  Initial  Problem  Statement  based  on  the  updated  requirements  and 
system  information  obtained  in  the  preceding  steps  of  Needs  Analysis. 

4.  SUMMARY  &  CONCLUSION 

We  have  attempted  to  highlight  two  main  themes  in  the  preceding  sections.  First,  we 
explained  our  design  methodology  used  to  produce  the  required  ADASIM  DoDAF 
documentation  contained  in  Appendix  C.  Second,  we’ve  offered  a  theoretical  way  to  inject 
process  into  the  creation  of  DoDAF  -  a  framework  which,  in  our  opinion,  is  largely  focused  on 
products.  This  process  has  demonstrated  how  systems  engineering  techniques  can  help  produce 
required  DoDAF  documents.  The  following  table  summarizes  the  mappings  of  several  of  these 
techniques  to  their  supported  DoDAF  counterparts: 


SEMP  Process 

DoDAF 

Views 

Supported 

27 


Initial  Problem  Statement 

OV-1 

Stakeholder  Analysis 

OV-1,  OV-2,  OV-3 

System  Decomposition 

OV-1,  OV-2,  SV-1 

Functional  Analysis 

OV-5,  OV-6C,  SV-6 

System  Engineering  Process  -  DoDAF  Mappings 


We  conclude  with  the  following  suggestion:  adhering  to  a  formalized  systems 
engineering  methodology  is  absolutely  essential  when  drafting  DoDAF  documentation. 

Focusing  solely  on  the  creation  of  a  suite  of  documents  will  not  necessarily  guarantee  success.  A 
deliberate  systems  engineering  process,  supported  by  other  systems  engineering  tools  and 
documentation,  will  greatly  enhance  the  functionality  and  interoperability  of  the  resultant 
architecture. 
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APPENDIX  A:  Operational  and  Summary  Information  (AV-1) 


The  Operational  and  Summary  Information  represents  the  overall  description  of  the  ADASIM 
project  and  associated  architecture.  It  is  primarily  populated  from  information  contained  in  the 
original  problem  statement  [5].  Additionally,  it  contains  project  details  gathered  during 
background  research  (facts  and  assumptions)  and  stakeholder  analysis. 


ADASIM  AV-1 

(Note:  This  is  an  interactive  document,  and  serves  as  a  gateway  to  all  architecture 
documents) 


IDENTIFICATION 

•'  '  A"'-.-'  .  - 

Name: 

Air  Defense  Artillery  (ADA)  Modeling  and  Simulation 
Architecture 

Architects: 

Department  of  Svstems  Enqineerinq 

Operations  Research  Center  of  Excellence  (ORCEN) 

United  States  Military  Academy,  West  Point,  NY 

10996 

POC:  MAJ  Steve  Henderson 

steven. henderson(®us.armv.mil 
(845)  938-3573 

Organization  Developing 
Architecture: 

Air  Defense  Artillery  Test  Directorate  (ADATD) 

Operational  Test  Command 

Fort  Bliss,  TX 

POC:  Mr.  Willie  Ratcliff 

Willie.  B.  Ratcliff (55otc.armv.mil 

915-637-1380 

Purpose: 

Provide  the  ability  to  evaluate  Air  Defense  Artillery 
systems  as  part  of  the  Operational  Test  Command 
Analytical  Simulation  and  Instrumental  Suite  (OASIS). 

training  applications  in  addition  to  their  primary  role 
of  supporting  operational  testing  [OASIS  ICD]. 


Operational  Realism.  OASIS  (and  ADSIM)  shall  be 
capable  of  incorporating  operational  realism  effects 
in  the  simulated  battlefield,  and  capturing 
operational  performance  data  as  a  result  of  these 
effects.  These  include  terrain  effects  on 
communications  and  mobility,  weather  effects,  other 
communications  effects,  non-military  entities,  and 
the  fidelity  of  entity  states.  OASIS  identifies  voids 
or  holes  impacting  the  ability  to  create  operational 
realism  and  works  to  develop  models,  simulations, 
and  instrumentation  necessary  to  fill  those  voids. 
Examples  of  these  voids  include  a  logistics  driver, 
electronic  attack  (synthetic  jamming  /  computer 
network  operations),  non-military  models  (refugees, 
vehicle  traffic,  cell  phones,  emergency  broadcast 
networks,  etc.)  and  many  threat  situations  to  cite  a 
few  examples.  When  equipped  with  appropriate 
scenarios,  databases,  and  simulation  interfaces, 
OASIS  Components  can  also  provide  support  to 
development  and  integration  testing,  training, 
exercises,  and  military  operations  planning  and 
analysis  [OASIS  ICD], 

Standards  Compliance.  OASIS  Components  [i.e. 
ADASIM]  shall  be  developed  in  accordance  with 
applicable  DoD  and  IEEE  standards  to  facilitate 
interoperability  and  compatibility  of  models  and 
instrumentation  for  distributed  test  and  evaluation 
[OASIS  ICD]. 

Functionality.  OASIS  Components  [i.e.  ADASIM] 
shall  provide  all  functionality  necessary  to  perform 
the  operational  tests  and  evaluations  of  the  FCS  and 
Future  Force,  including  lethality,  C4ISR,  Battle 
Command,  Maneuver  Support,  Deployability  / 
Transportability,  Tactical  Maneuver  /  Mobility, 
Survivability,  Sustainability,  Interoperability,  and 
Training  [OASIS  ICD], 

Compatibility.  OASIS  Tools  [i.e.  ADASIM]  shall 
be  compatible  with  other  standards  conformant 
models  and  instrumentation  [OASIS  ICD], 

Data  Management.  OASIS  Tools  [i.e.  ADASIM] 
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shall  provide  the  capability  for  both  centralized  and 
de-centralized  data  collection,  reduction, 
aggregation,  analysis,  evaluation,  and  presentation 
[OASIS  ICD], 

Communications.  OASIS  Components  [i.e. 
ADASIM]  shall  support  multiple  simultaneous 
communications  interfaces  such  as  Wide  Area 
Networks,  Local  Area  Networks,  Satellite,  and 
tactical  radio  over  a  variety  of  transmission  media 
for  both  voice  and  data  [OASIS  ICD]. 

Information  Security.  All  OASIS  Components  [i.e. 
ADASIM]  shall  be  tested  and  approved  to  process  a 
variety  of  information  ranging  from  Unclassified 
through  Top  Secret  Special  Compartmented 
Intelligence  using  either  the  DITSCAP  or  DODIIS 
process.  The  Certification  and  Accreditation  (C&A) 
requirements  for  each  OASIS  component  shall  be 
determined  by  the  security  classification  of  the 
information  that  component  processes.  The 
developer  of  each  component  must  support  and 
execute  this  C&A  testing.  Each  federation  of 
OASIS  Components  must  be  tested  and  approved  to 
process  classified  information  at  the  level  specified. 
OASIS  tools  shall  be  managed  through  a  centralized 
OASIS  Configuration  Management  organization  and 
process  [OASIS  ICD], 

Distributed.  OASIS  Components  [i.e.  ADASIM] 
shall  perform  and  support  distributed  modeling  and 
simulation.  The  operational  elements  of 
interoperability,  standards  compliance, 
compatability,  communications,  and  information 
security  enable  OASIS  Components  to  participate  in 
and  utilize  distributed  modeling  and  simulation. 
[OASIS  ICD] 

ADASIM  will  support  test  and  evaluation  of  the 
multi-mission  radar  (MMR).  This  system  is  the 
primary  source  of  detecting  air  threats  manned  and 
unmanned.  ADASIM  will  be  able  to  emulate  this 
sensor  function  in  the  early  stages  of  SOS  testing, 
and  stimulate  the  radar  for  later  testing  events. 


•  ADASIM  will  support  the  testing  of  FCS  systems 
[MAJ  Matty  Email] 


ADASIM  will  support  the  testing  FCS  systems  that 
use  alert  warning  information  to  resolve  a  fire 
control  solution  on  helicopters  and  UAVs  using 
integral  fire  control  system.  [ADASIM  White  Paper] 


ADASIM  will  support  the  testing  of  FCS  systems  as 
they  conduct  LOS  CAFADS  engagements  within 
the  capabilities  of  embedded  weapons.  [ADASIM 
White  Paper] 


Assumptions: 

•  Implementing  simulation  designs  employing  the 
ADASIM  architecture  will  be  based  on  a  discrete 
event  simulation  paradigm.  A  discrete  event 
simulation  models  a  system  as  it  evolves  over  time 
where  system  entities  change  instantaneously  at 
discrete  points  in  time  [See  Law/Kelton,  6].  This 
assumption  is  critical  in  our  suggested  OV-5  and 
OV6c  documents. 


ARCHITECTURE  IDENTIFICATION 


ADASIM 
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Views  and  Products  AV-1  -  Operational  and  Summary  Information 

OV-1  -  Operational  Concept  Description 
OV-2  -  Node  Connectivity  Diagram 
OV-3  -  Information  Exchange  Matrix 


OV-5  -  Operational  Activity  Diagram 

OV-6c  -  Operational  Sequence  Diagram 

SV-1  -  System  Interface  Description 

SV-6  -  System/Service  Information  Exchange  Req 
Matrix 


AV-2  -  Integrated  Dictionary 
Technical  Report 


PURPOSE  AND  VIEWPOINT 


Questions  to  be  Answered 
by  Analysis  of  Architecture: 


•  What  are  the  operational  requirements  for  the 
systems  under  this  architecture? 

•  What  are  the  deficiencies  in  the  current 
capabilities? 

•  What  are  the  requirements  for  a  new  system  to 
meet  the  deficiencies? 

•  Which  approach  best  meets  needs  regarding  ADA 
products  developed/acquired? 

•  What  is  the  test  planning  process  for  the  ADA 
systems  developed  under  this  architecture? 

•  Which  Architecture  products  are  used  for  testing 
and  when? 

•  How  will  interoperability  be  evaluated  using  the 
architecture? 


•  How  do  ADA  products  measure  up  for 
interoperability? 

•  What  are  the  interoperability  gaps  that  need  to  be 
fixed? 


How  do  existing  products  fit  into  the  new 
architecture? 


•  What  is  the  test  architecture  for  a  given  test,  using 
the  ADA  architecture? 

•  What  are  the  impacts  of  changes  to  the  System 
Under  Test  (SUT)  on  the  architecture  and  the  M&S 
products? 

From  Whose  Viewpoint  is 
the  Architecture  Described: 

An  analyst  who  has  little  to  no  background  in  Air 
Defense  Systems 

context 

Mission 

Air  Defense 

Doctrine,  Goals,  and  Vision 

Air  Defense 

Expected  Threats 

All  known 

Geographical  Area 

Addressed 

Non-specific 

;  Tools  and  File  Formats 

Microsoft  PowerPoint :  OV1 ,  OV2,  SV1 

Microsoft  Excel :  AV2,  OV3,  SV6 

Microsoft  Vision  2002  :  OV5,  OV6c 

HTML:  AVI 

Findings 

1  -  -  :: _ ; _  -  _ _ _ _ _ : _ _ _ : _ Lii _ ! _  -  -  _ ■  ■■'■■■■ 

Analysis  Results: 

See  ADASIM  Technical  Report 

See  ADASIM  Technical  Report 


Recommendations: 


APPENDIX  B:  ADASIM  Integrated  Dictionary  (AV-2) 


The  ADASIM  Integrated  Dictionary  contains  definitions  of  all  relevant  terms  and  abbreviations 
contained  in  any  of  the  ADASIM  DoDAF  documents.  These  terms  were  collected  throughout 


the  entire  design  process. 


iUSS 

-..■I 

ABT  Threat 

Air-breathing  threats. 

OV-1 

Acknowledqe 

A  message  from  a  receiver  to  a  sender  telling  the  sender  that 
the  receiver  received  and  understands  the  last  transmission. 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

A  special  mode  of  radar  when  the  radar  is  searching  for 
targets. 

OV6C  :  Engage  Threat 

A  special  mode  of  radar  when  the  radar  has  acquired  a  target 
and  continually  updates  the  target  location,  speed,  attitude, 
etc. 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

ADASIM 

Air  Defense  Artillery  Simulation  Architecture. 

ALL 

ADASIM  Node 

The  node  in  the  simulation  architecture  responsible  for  control 
of  the  simulation. 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

Air  Defense  Warning 

A  degree  of  air  raid  probability  according  to  the  following  code. 
The  term  air  defense  division/sector  referred  to  herein  may 
include  forces  and  units  afloat  and/or  deployed  to  forward 
areas,  as  applicable.  The  initial  declaration  of  air  defense 
emergency  will  automatically  establish  a  condition  of  air 
defense  warning  other  than  white  for  purposes  of  security 
control  of  air  traffic.  See  FMs  44-63  and  44-100. 

Airborne  C4  Node 

An  airborne  command,  control,  communications,  and 
computers  svstem 

OV-1 

Airborne  Sensor 

Any  sensor  deployed  in  the  air 

OV-1 

Airborne  Weapon 

Any  weapons  system  that  is  primary  deployed  in  the  air. 

OV-1 

Airspace  Control  Measure 

Rules,  mechanisms,  and  directions  governed  by  joint  doctrine 
and  defined  by  the  airspace  control  plan  which  control  the  use 
of  airspace  of  specified  dimensions.  (See  also  high-density 
airspace  control  zone  (HIDACZ),  low-level  transit  route 
(LLTR),  minimum-risk  route  (MRR),  and  standard  use  Army 
aircraft  flight  route  (SAAFR).)  See  FM  100-103. 

OV-5 

Air  Missile  Defense 

SV-1 

AMDTF  System 

A  system  that  is  part  of  the  Air  Missile  Defense  Task  Force. 

SV-1 

Analysis  Tool 

A  tool  used  to  analyze  the  results  of  the  simulation 

SV-1 

Assessing 

The  process  of  determining  the  effectiveness  of  an 

OV-2 
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Communicate  Component 


Data  Collection  Process 


Earlv  Warning  Plan 


Elevated  Sensor 


Enemy  State 


Engagement 


Event  Directives 


Event  List 


The  process  of  designating  a  particular  weapons  system  for 
an  engagement. 


n  urgent  or  priority  Air  Defense  Warnin 


\  higher  headquarters'  guidance  on  the  conduct,  timing,  and 
arget  priorities  of  an  attack  operation. 


re-FCS  ere  US  Armv  air  defense  system. 


The  act  of  sending  a  message  to  more  than  one  station  at  the 
same  time. 


Command,  control,  communications  and  computers. 


command,  control,  communications  and  computers  node.  lOV-1 


he  simulation  clock  that  is  used  to  synchronize  all  simulation 
events. 


Common  Logistics  operating  Element. 


n  enemy  cruise  missile  threat. 


The  process  in  which  two  or  more  entities  combine  information 
and  assets  to  engage  a  target. 


The  process  in  which  two  or  more  entities  combine  information 
and  assets  to  track  a  target. 


Information  required  by  the  commander  that  directly  affects  his 
decisions  and  dictates  the  successful  execution  of  operational 
or  tactical  operations.  CCIR  normally  result  in  the  generation 
of  three  types  of  information  requirements:  priority  intelligence 
requirements,  essential  elements  of  friendly  information,  and 
friendly  force  information  requirements. 


A  single  identical  display  of  relevant  information  shared  by 
more  than  one  command.  A  common  operational  picture 
facilitates  collaborative  planning  and  assists  all  echelons  to 
achieve  situational  awareness.  SV-1 


Those  simulation  services  that  are  common  to  all  nodes  - 
terrain  databases,  weather  effects,  etc.  SV-1 


The  part  of  a  simulation  node  responsible  for  communicating 
ith  other  nodes.  SV-1 


Common  Operational  Picture/Common  Relevant  Operational 
Picture  OV-2 


simulation  message  instructing  the  simulation  to  load  the 
irst  mission  OV6C  :  Sustain  Air  Defense  Operations 


simulation  message  instructing  the  simulation  to  load  initiate 
he  simulation.  OV6C  :  Provide  Air  Defense  Command  and  Control 


lA  process  within  the  simulation  dedicated  to  collecting  raw 

data  for  later  analysis.  SV-1 


The  plan  detailing  the  actions  for  early  notification  of  the 

launch  or  approach  of  unknown  weapons  or  weapon  carriers  OV-5 


l  sensor  that  is  permanently  airborne  (via  blimp,  airship,  etc).  OV-1 


Current  information  about  a  threat  entity's  state  -  location, 
attitude,  disposition,  strength,  or  any  other  attribute  describing 
the  threat  entity  at  the  current  time.  SV-1 


The  process  of  one  entity  firing  on  another  with  the  goal  of  IOV6C  :  Engage  Threat 
disabling  or  destroying  it.  OV6C  :  Take  Active  AD  Measures 


lActions  that  each  node  will  conduct  for  a  particular  simulation 
levent.  SV-1 


list  of  all  current  and  future  events  within  the  simulation. 
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External  Sensor  Node 

The  node  in  the  simulation  architecture  responsible  for 
simulating  all  sensors  that  are  external  to  Army  systems  - 
satellites,  off-shore  radar,  AWACs,  etc. 

External  Tracking  Info 

Information  about  a  target  that  originates  from  an  external 
system. 

FCS 

The  Future  Combat  Systems  (FCS)  is  a  joint  (across  all  the 
military  services)  networked  (connected  via  advanced 
communications)  systems  of  systems  (one  large  system  made 
up  of  18  individual  systems  plus  the  network  and  Soldier- 
often  referred  to  as  18  plus  one  plus  one). 

FCS/FIFV  (MC) 

The  future  infantry  fighting  vehicle  (FIFV)  for  the  future  combat 
system  (FCS). 

Fire  Command 

A  specific  seguence  of  information  given  by  a  control  authority 
(for  example,  a  vehicle  commander  or  fire  direction  center) 
that  causes  a  crew  to  begin  performing  a  sequence  of  actions 
and  provides  detailed  direction  to  choose  the  ammunition 
type,  aim  the  weapon,  and  engage  the  target.  Each  element 
given  by  the  controller  requires  a  response  from  a  crew 
member  to  ensure  correct  aiming  and  engagement.  After  the 
initial  fire  command,  subsequent  fire  commands  using  the 
same  sequence  of  information  can  be  used  to  adjust  the  point 
of  impact  to  ensure  the  desired  target  effect.  See  FMs  6- 
series,  7-90,  7-91,  17-12,  and  23-1. 

Fires  Sensor  Node 

The  node  in  the  simulation  architecture  responsible  for 
simulating  those  native  systems  that  fire  and  sense  -  e.g.  A 
Patriot  Missile  Battery 

Fragmentary  Order  (FRAGO) 

An  abbreviated  form  of  an  operation  order,  usually  issued  on  a 
day-to-day  basis,  which  eliminates  the  need  for  restating 
information  contained  in  a  basic  operation  order.  It  may  be 
issued  in  sections. 

FRAGO 

See  Fragmentary  Order. 

FW 

Fixed-wing. 

General  Orders 

General  instructions  from  a  higher  headquarters  to 
subordinates.  Include  Fire  commands,  Weapons  Control 
Status,  Rules  of  Engagement,  Target  Priorities,  Commanders 
Critical  Information  Requirements,  Attack  Alarms,  Air  Defense 
Warnings. 

GUI  Data 

Simulation  data  pertaining  to  the  functionality  of  the  Graphical 
User  Interface  (GUI) . 

Headguarters  Node 

The  node  in  the  simulation  architecture  responsible  for 
simulating  all  command  and  control  activities. 

Higher  HQ  FRAGO 

A  Fragmentary  Order  oriqinatinq  from  hiqher  headquarters. 

HQ 

Headquarters. 

HSOC 

Home  station  operating  station. 

IFF 

Identify  Friend  or  Foe. 

IFF  Procedures 

Specific  instructions  on  how  to  identify  friend  or  foe  (given  an 
unknown  target). 

0V6C :  Engage  Threat 

0V6C  :  Take  Active  AD  Measures 

0V6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 


OV6C :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV-1 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

OV6C  :  Adjust  AD  Coverage 

SV-1 

OV6C  :  Provide  Air  Defense  Command  and  Control 

OV-2 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

OV6C  :  Adjust  AD  Coverage 

OV-5 

SV-1 

OV-5 

OV-5 
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Initialize 

C 

C 

C 

C 

A  simulation  message  instructing  entities  to  perform  all  pre-  C 
simulation  tasks.  C 

JDN 

Joint  Data  Network.  £ 

JLENS 

Joint  Land  Attack  Cruise  Missile  Defense  Elevated  Netted 
Sensor  System  .  £ 

Joint  Data  Network 

A  common  DoD  network  used  by  all  services.  £ 

Landline 

Commercial  telephone  lines  or  military  eguivalent.  £ 

Linebacker 

A  pre-FCS  ere  US  Army  air  defense  system.  £ 

Logistics  Info 

Information  pertaining  to  the  logistical  readiness  and  state  of  a 
system  or  node.  £ 

LOS/BLOS  WPN 

The  Line-of-Sight  /  Beyond  Line-of-Sight  (LOS/BLOS)  weapon 
is  a  FCS  combat  vehicle  with  105-1 20mm  cannon  with 
LOS/BLOS  capability.  It  will  be  developed  in  the  FCS  120mm 
LOS/BLOS  ATD.  Also  included  is  a  Self  Protection  Weapon. 

M3P  System 

Multi-Mission  Mobile  Processor. 

MEADS  BTRY 

A  Medium  Extended  Air  Defense  System  battery  of  air 
defense  artillery. 

Messages 

Simulation  messages  that  synchronize  and  coordinate  activity 
between  multiple  simulation  nodes. 

METT-TC 

Mission,  Enemy,  Time,  Troops,  Time,  Civilians 

MRM 

Medium  Range  Missile. 

MULE 

Multifunction  Utility/Logistics  Equipment  Vehicle  (robotic 
vehicle  intended  to  support  dismounted  troops) . 

Network 

A  common  simulation  network  linking  two  or  more  disparate 
simulations  or  nodes. 

Next  Mission 

A  simulation  message  instructing  participating  entities  to  load 
their  next  scripted  mission. 

NLOS WPN 

A  non-line  of  sight  weapon  system.  The  NLOS  weapon 
system  is  an  FCS  combat  vehicle  with  120-1 55mm  cannon 
with  NLOS  capability.  This  system  incorporates  technologies 
that  include  CARGO  rounds  and  smart  sub  munitions,  and 

Fire  and  Forget  Seeker  technology.  Also  included  is  a  Self 
Protection  Weapon. 

Node  metrics 

Measurable  values  that  reflect  the  performance  metrics  of  the 
node  and  its  subordinate  objects.  See  Performance  Metrics. 

Operations  Order 

A  directive  issued  by  the  commander  to  subordinate 
commanders  for  the  purpose  of  affecting  the  coordinated 
execution  of  an  operation 

Orders 

General  instructions  from  a  higher  headquarters  to 
subordinates.  Include  Fire  commands,  Weapons  Control 
Status,  Rules  of  Engagement,  Target  Priorities,  Commanders 
Critical  Information  Requirements,  Attack  Alarms,  Air  Defense 
Warnings. 

0V6C  :  Provide  Air  Defense  Command  and  Control 


SV-1 


OV6C  :  Plan  and  Coordinate  Air  Defense 


OV6C  :  Engage  ThreatOV6C  :  Take  Active  AD 
MeasuresOV6C  :  Sustain  Air  Defense 
OperationsOV6C  :  Plan  and  Coordinate  Air 
DefenseOV6C  :  Adjust  AD  CoverageOV6C  : 
Provide  Air  Defense  Command  and  ControlSV-1 


OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Provide  Air  Defense  Command  and  Control 
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Output 

General  output  from  the  simulation  to  the  user.  i.e.  -  metrics, 
feedback,  error  reports,  status,  etc. 

SV-1 

Post-Simulation  Analysis 

[The  process  of  analyzing  the  simulation  results  to  determine 
the  effectiveness  of  the  system  under  test. 

SV-1 

Prepare  for  New  Mission 

A  message  from  a  higher  headquarters  to  a  subordinate  unit 
instructing  them  to  prepare  for  a  new  mission  (See  Warning 
Order) 

OV6C  :  Plan  and  Coordinate  Air  Defense 

Ready  for  Next  Event 

A  simulation  message  indicating  the  simulation  is  ready  to 
process  its  next  scheduled  event. 

OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

Report  Generation 

A  simulation  process  (usually  done  during  post-simulation 
analysis)  where  custom  reports  are  created  to  help  analyze 
the  results  of  the  simulation. 

SV-1 

RF 

Radar  frequency. 

SV-1 

Robotic  Mortar  FCS/AREMS 

A  largely  automated  mortar  weapon  system  in  the  Future 
Combat  Systems  suite  of  vehicles. 

OV-1 

Robotic  Mule 

1 

The  Multifunction  Utility/Logistics  Equipment  Vehicle  (MULE) 
is  an  unmanned  platform  that  provides  transport  of  equipment 
and/or  supplies  in  support  of  dismounted  maneuver 

OV-1 

Rotary  Threat 

An  enemy  helicopter. 

OV-1 

Directives  issued  by  competent  military  authority  which 

Rules  of  Engagement 

delineate  the  circumstances  and  limitations  under  which  US 
forces  will  initiate  and/or  continue  combat  engagement  with 
other  forces  encountered.  See  FM  100-20. 

OV-6c,  OV-5 

RW 

Rotary-wing. 

SV-1 

Scenario 

A  set  of  terrain,  weather,  friendly  forces,  enemy  forces,  and 
missions  used  to  define  a  particular  instance  of  a  simulation. 

SV-1 

Scenario  Execution 

The  process  of  running  a  scenario  from  start  to  finish. 

SV-1 

Scenario  Generation 

The  process  of  creating  a  scenario. 

SV-1 

Scenario  Playback 

The  process  of  watching  a  scenario  again,  after  it  has  already 
been  simulated. 

SV-1 

Sense  Component 

The  part  of  a  simulation  node  responsible  for  sensing  external 
objects  and  events. 

SV-1 

Simulation  Metrics 

Simulation  data  pertaining  to  the  inner  workings  of  the 
simulation. 

SV-1 

SLAMRAAM 

The  Surfaced-Launched  Advanced  Medium  Range  Air-to-Air 
Missile  (SLAMRAAM)  is  the  Army's  future  short-range  air 
defense  weapon 

OV-1 

Space-based  Sensor 

A  sensor  that  is  located  on  a  space-based  platform. 

OV-1 

Space-based  system 

A  system  that  is  located  on  a  space-based  platform. 

SV-1 

Start  Monitoring  SUT 

A  cue  to  start  monitoring  the  System  Under  Test  (SUT) 

OV6C  :  Engage  ThreatOV6C  :  Take  Active  AD 
MeasuresOV6C  :  Sustain  Air  Defense 
OperationsOV6C  :  Plan  and  Coordinate  Air 
DefenseOV6C  :  Adjust  AD  CoverageOV6C  : 
Provide  Air  Defense  Command  and  Control 

State  data 

See  State  Information. 

SV-1 

State  Info 

Current  information  about  an  entity's  state  -  location,  attitude, 
disposition,  strength,  or  any  other  attribute  describing  the 
threat  entity  at  the  current  time. 

SV-1 
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Sustainment  Activi 


Sustainment  Demand 


Sustainment  Plan 


The  node  in  the  simulation  architecture  responsible  for 
simulatinq  all  support  or  logistics  activities. 


ny  process  that  provides  personnel,  logistic,  and  other 
support  activi 


m 


OV6C :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 


i 

OV6C  :  Sustain  Air  Defense  Operations 


IOV6C  :  Sustain  Air  Defense  Operations 


Personnel,  logistic,  and  other  support  requirements. 


The  plan  detailing  the  provision  of  personnel,  logistic,  and 

other  support  required  to  maintain  and  prolong  operations  or  OV-5, 

combat.  OV6C  :  Sustain  Air  Defense  Operations 


Synchronization 


System  Under  Test 


arget  Priorities 


est  Execution 


HAAD  BTRY 


hinker  Component 


The  process  of  synchronizing  simulation  events  across 
multiple  simulation  nodes. 


he  Air  Defense  System  being  tested  by  the  simulation. 


i  list  of  which  targets  should  be  fired  on  before  other  targets. 


Information  required  by  weapons  systems  to  compute  a  firing 
solution  for  and  engage  a  target. 


actical  ballistic  missile. 


Simulation  data  pertaining  to  the  design  and  conduct  of  the 
test. 


The  actual  execution  of  the  test  that  uses  the  ADASIM. 


he  design  of  and  preparation  for  the  test  that  will  use  the 
DASIM  . 


The  node  in  the  simulation  architecture  responsible  for 
interfacing  with  the  test  managers. 


Theater  High-Altitude  Area  Defense  ITHAAD1  batte 


[The  part  of  a  simulation  node  responsible  for  processing 
information  and  making  decisions. 


[OV-2,  OV-5 


OV6C  :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 


hreat  Signature 


hreat  State  Information 


racking  &  Collaborative 
Engagement  Command 


UAV  Threat 


lA  measurable  &  detectable  emission  from  any  enemy  object  -  OV6C  :  Engage  Threat 

li.e.  sound,  light,  radar  signature,  etc.  OV6C  :  Take  Active  AD  Measures 


OV6C  :  Engage  Threat 

See  Threat  State  Information.  OV6C  :  Take  Active  AD  Measures 


Current  information  about  a  threat  entity's  state  -  location, 

attitude,  disposition,  strength,  or  any  other  attribute  describing  OV6C  :  Engage  Threat 

the  threat  entity  at  the  current  time.  OV6C  :  Take  Active  AD  Measures 


OV6C  :  Engage  Threat 
OV6C  :  Take  Active  AD  Measures 
OV6C  :  Sustain  Air  Defense  Operations 
OV6C  :  Plan  and  Coordinate  Air  Defense 

The  node  in  the  simulation  architecture  responsible  for  OV6C  :  Adjust  AD  Coverage 

simulating  enemy  or  threat  activity.  OV6C  :  Provide  Air  Defense  Command  and  Control 


special  mode  of  radar  when  the  radar  has  acquired  a  target 
and  continually  updates  the  target  location,  speed,  attitude, 
etc. 


command  facilitating  a  collaborative  engagement  or 
collaborative  trackin 


Unmanned  aerial  vehicle. 


OV6C  :  Engage  Threat 
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Updated  Simulation  Metrics 

Measurable  values  that  reflect  the  relative  performance  of  the 
simulation  or  simulation  objects.  For  example,  a  simulated 
probability  of  kill. 

OV6C :  Engage  Threat 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  Operations 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

Updated  State  Information 

Current  information  about  a  simulation  entity’s  state  -  location, 
attitude,  disposition,  strength,  or  any  other  attribute  describing 
that  entity  at  the  current  time. 

OV6C  :  Take  Active  AD  Measures 

OV6C  :  Sustain  Air  Defense  OperationsOV6C  : 

Plan  and  Coordinate  Air  Defense 

OV6C  :  Adjust  AD  Coverage 

OV6C  :  Provide  Air  Defense  Command  and  Control 

User  Input 

General  input  (commands,  responses)  from  the  user  to  the 
simulation. 

SV-1 

VTOL  FCSA/AAV 

A  vertical  take-of  unmanned  aerial  vehicle. 

OV-1 

Warning  Order 

A  planning  directive  that  describes  the  situation,  allocates 
forces  and  resources,  establishes  command  relationships, 
provides  other  initial  planning  guidance,  and  initiates 
subordinate  unit  mission  planning. 

OV6C  :  Plan  and  Coordinate  Air  Defense 

OV5 

Weapons  Control  Status 

The  degree  of  fire  control  imposed  upon  Army  units  having 
assigned,  attached,  or  organic  air  defense  weapons. 

Weapons  control  status  terms  are:  weapons  free,  weapons 
tight,  and  weapons  hold.  See  FMs  44-63  and  44-100. 

OV-5,  OV-6c 
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APPENDIX  C:  ADASIM  Operational  Concept  Diagram  (OV-1) 


The  ADASIM  OV-1  (Figure  C-3)  represents  the  top  operational  view  of  the  ADASIM 
simulation  architecture.  This  diagram  sets  the  context  and  scope  of  the  ADASIM  architecture, 
and  follows  from  the  system  decomposition  process  discussed  in  earlier  sections.  The  boundary 
of  the  ADASIM  architecture  is  represented  by  the  set  of  all  major  battlefield  systems  that  might 
appear  in  a  particular  Air  Defense  simulation.  These  objects  form  the  components  and  sub¬ 
components  of  our  ADASIM  architecture,  and  will  appear  as  entities  in  any  implementing 
simulation.  These  entities  might  represent  a  particular  system  under  test  (e.g.  SLAM/RAAM)  or 
potential  targets  (e.g.  UAV  Threat). 

We  enumerated  the  components  in  this  view  during  an  affinity  diagramming  exercise.  This 

affinity  diagramming  process,  a  structured  brain-storming  exercise,  pulled  entities  from  three 

\ 

primary  areas.  First,  we  examined  current  Air  Defense  doctrine,  and  extracted  the  major  systems 
currently  appearing  on  the  modem  battlefield.  Second,  because  the  ADASIM  will  largely 
support  the  fielding  of  new  systems,  we  also  researched  Future  Combat  System  literature  to 
identify  important  future  battlefield  systems.  Third,  we  leveraged  the  experience  of  military 
personnel  with  experience  in  the  Air  Defense  domain. 

The  diagram  also  features  visual  depictions  of  particular  simulation-specific  features  of  the 
ADASIM  architecture.  This  helps  define  the  scope  of  functionality  that  ADASEM-based 
simulations  will  provide.  In  the  center  of  the  diagram,  we  show  three  parallel  planes.  These 
planes  represent  the  various  states  of  existence  of  participating  systems.  A  system  participating 
in  an  ADASIM-based  simulation  might  be  a  live  physical  system  (hardware-in-the-loop). 
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constructive  (a  partially  implemented  prototype),  or  completely  virtual.  Any  ADASIM 
compliant  simulation  will  handle  any  of  the  three  types. 


The  “Wrap  Around  Environment”  circle  represents  a  common  simulation  environment  that  cuts 
across  all  participating  entities  in  the  system.  This  environment  is  made  up  of  common 
simulation  services  that  are  shared  by  two  or  more  entities.  These  include  common  terrain 
databases,  data  management  functions,  event  handling,  and  network  management  functions. 


APPENDIX  D  :  ADASIM  Node  Connectivity  Diagram  (OV-2) 

The  OV-2  is  made  up  of  seven  functional  nodes.  Each  node  represents  a  particular  functional 
theme  exhibited  by  components  that  participate  in  an  ADASIM-based  simulation.  Each  of  these 
nodes  encapsulates  the  common  tasks,  modeling  aspects,  and  algorithms  that  are  needed  to 
implement  each  particular  function. 

The  ADASIM  Node  is  the  central  node  in  the  architecture.  This  node  models  all  simulation- 
specific  tasks.  These  tasks  include,  but  are  not  limited  to  the  following:  simulation  timing,  event 
list  management,  message  passing,  interface  with  simulation/test  managers,  and  interface  with 
external  simulation  federations,  conflict  resolution,  and  integration  of  common  services. 

The  Testers  Node  represents  the  tasks  and  functionality  required  to  interface  with  the  ADASIM 
Test  Managers.  This  includes  simulation  input,  simulation  output,  GUI  generation,  simulation 
scenario  modeling,  and  management  of  performance  measures  and  other  simulation  assessment 
mechanisms. 

The  Fires/Sensor  Node  encapsulates  the  simulation  of  those  battlefield  systems  that  have  organic 
weapons  and  sensors.  For  example,  the  Army’s  Avenger  weapons  system  has  both  onboard 
weapons  and  sensors. 

The  External  Sensors  Node  represents  the  simulation  of  any  external  sensor  system. 
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The  Threats  Node  is  responsible  for  representing  enemy  simulation  entities.  Grouping  threat 
entities  into  a  common  node  allows  the  architecture  to  better  model  characteristics  common  to  all 
threat  objects.  For  example,  enemy  doctrine,  language,  or  a  common  enemy  battleplan. 

The  Support  Node  represents  the  entities  in  the  simulation  that  provide  logistics  support  to  other 
entities. 

The  Headquarters  Node  manages  all  Command  and  Control  entities  in  the  simulation.  Particular 
functionality  includes  simulation  of  communications  networks,  decision  making,  and  common- 
operating  picture  representation. 

The  diagram  also  details  high-level  information  exchange  between  the  nodes.  These  information 
exchange  requirements  are  summarized  in  the  Information  Exchange  Matrix  (OV-3  at  Appendix 
E). 
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APPENDIX  E  :  ADASIM  Information  Exchange  Matrix  (OV-3) 


The  information  exchange  matrix  describes  the  critical  information  that  flows  between  each  node 
(See  OV-2  at  Appendix  D).  The  information  was  derived  during  our  fact  gathering  process, 
stakeholder  analysis,  and  functional  analysis.  Additionally,  as  we  constructed  the  OV-6c 
(Operational  Sequence  Diagram)  we  captured  critical  information  flows  that  were  required  to 
achieve  the  desired  level  of  functionality. 

This  information  is  expounded  in  the  SV-6  (Appendix  I).  The  SV-6  shows  a  more  refined  view 
of  the  specific  types  of  messages  that  make  up  the  broad  categories  list  in  the  OV-3. 
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Information  Consumer  Consumer  Consumer  Producer  Producer  Producer  Communication 

Requirement  Node  Element  Process  Node  Element  Process _ Characteristic  Speed  of  Service  Frequency  Perishabilit 

Fires/Sensor  Execute  Air  Attack  Headquarters  Headquarters  Issue  Air  Attack 

Air  Attack  Alarm  Node  Shooter/Sensor  Alarm _ Node _ Element _ Alarm _ Digital  or  voice _ Rapid _ Low _ Low _ 


External  External  Execute  IFF  Headquarters  Headquarters  Issue  IFF 

IFF  Procedures  Sensor  Sensor  System  Procedures _ Node _ Element _ Procedures _ Digital  or  voice 

Support  Execute  IFF  Headquarters  Headquarters  Issue  IFF 

IFF  Procedures  Node _ Support  Node  Procedures _ Node _ Element _ Procedures _ Digital  or  voice 


ADASIM  ADASIM  Headquarters  Headquarters 

Node  Metrics  Node  Implementation  Compute  Metrics  Node  Element  (All  Processes)  Digital  _ Rapid _ Medium 


let  Priorities  INode_ ISupport  Node  [Priorities_ iNode_ lElement_ Priorities_ iDigital  or  voice_ Rapid |Low_ I  Low 


Threat  External  External  Execute  Enemy 

Signature  Sensor  Sensor  System  Search  for  Threat  Threat  Node  Threat  System _ Mission _ Radar,  IR,  visual,  acoustic  Instantaneous  High _ High 


Appendix  F  :  Operational  Activity  Diagram  (OV-5) 

The  OV-5  is  divided  into  seven  sub-documents: 

Simulation  Control 

Engage  Threat  Event 

Plan  and  Coordinate  Air  Defense  Event 

Take  Active  Air  Defense  Event 

Sustain  Air  Defense  Event 

Provide  Air  Defense  Command  and  Control  Event 
Adjust  Air  Defense  Coverage  Event 

The  Simulation  Control  OV-5  shows  the  top  level  functionality  of  ADASIM.  The  diagram 
begins  with  ADASIM  performing  common  simulation  initialize  functions  -  i.e.  designation  of  a 
system  under  test,  scenario  design,  etc.  The  simulation  then  proceeds  to  build  an  initial  master 
simulation  event  list.  This  event  list  is  populated  based  on  initial  events  contained  in  the 
simulation  scenario. 

The  simulation  then  proceeds  with  the  following  loop,  until  no  more  simulation  events  are  left  on 
the  simulation  event  list.  The  simulation  first  executes  the  next  simulation  event,  which  is  one  of 
six  top-level  Air  Defense  mission  events  encountered  by  ADASIM:  Engage  Threat  Event,  Plan 
and  Coordinate  Air  Defense  Event,  Take  Active  Air  Defense  Event,  Sustain  Air  Defense  Event, 
Provide  Air  Defense  Command  and  Control  Event,  or  Adjust  Air  Defense  Coverage  Event.  Each 


of  these  events  is  further  refined  in  its  own  individual  OV-5,  and  contains  smaller  simulation 
events  (e.g.  Track  Threat,  Receive  OPORD,  etc). 

The  smaller  simulation  events  were  extracted  from  current  ADA  doctrinal  publications  (ARTEP 
MTPs).  For  each  ADA  Mission  event  (Engage  Threat  Event,  Plan  and  Coordinate  Air  Defense 
Event,  Take  Active  Air  Defense  Event,  etc),  we  looked  at  the  doctrinal  steps  that  are  required  for 
satisfactory  completion  of  that  top-level  mission  event.  These  steps  represent  the  low-level 
functions  in  each  OV-5  diagram. 

Once  completing  the  entire  Air  Defense  mission  event,  the  simulation  returns  to  the  Simulation 
Control  OV-5,  records  any  metrics,  generates  any  new  events  resulting  from  the  last  one.  The 
simulation  loops  back  and  grabs  the  next  simulation  event  (if  applicable)  or  computes/reports 
final  metrics  and  ends  the  simulation. 

The  actual  OV-5  is  omitted  from  this  document  due  to  its  size.  The  actual  OV-5  can  be  obtained 
through  the  Operations  Research  Center  of  Excellence  or  via  the  Internet  at 
http://www.orcen.usma.edu/adasim/index.asp 
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Appendix  G:  OV-6C  :  Operational  Sequence  Diagram 


The  ADASIM  Operational  Sequence  diagram  contains  six  sub-documents:  Simulation  Control, 
Engage  Threat  Event,  Plan  and  Coordinate  Air  Defense  Event,  Take  Active  Air  Defense  Event, 
Sustain  Air  Defense  Event,  Provide  Air  Defense  Command  and  Control  Event,  Adjust  Air 
Defense  Coverage  Event.  Each  of  these  corresponds  to  an  associated  OV-5  sub-document. 

Each  OV-6C  shows  the  low  level  sequence  of  events  for  each  of  the  six  major  Air  Defense 
mission  events.  The  diagrams  also  show  low-level  information  exchanges  between  modes  that 
occur  during  each  low-level  function.  These  low-level  messages  are  numbered,  and  are 
described  in  the  SV-6  (System/Service  Information  Exchange  Requirements  Matrix).  This 
documents  is  provided  at  Appendix  I. 

The  interaction  between  nodes  represents  the  node-node  communication  that  corresponds  to  each 
of  the  sub-functions  listed  in  the  OV-5.  As  mentioned  in  Appendix  F,  these  function  represent 
the  necessary  doctrinal  steps  required  for  successful  completion  of  the  top-level  ADA  mission 
event  (Engage  Threat  Even,  Plan  and  Coordinate  Air  Defense  Event,  Take  Active  Air  Defense 
Event,  etc). 

The  actual  OV-6  is  omitted  from  this  document  due  to  its  size.  The  actual  OV-6  can  be  obtained 
through  the  Operations  Research  Center  of  Excellence  or  via  the  Internet  at 
http://www.orcen.usma.edu/adasim/index.asp 
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Appendix  H:  SV-1  (System  Interface  Description) 

The  SV-1  describes  the  general  design  and  functionality  of  the  six  principal  ADASIM 
nodes.  This  includes  a  description  of  interfaces  each  node  maintains  with  other  nodes  well  as 
common  ADASIM  services. 

The  general  functionality  provided  by  each  node  is  broken  into  four  primary  components 
-  a  communications  component,  a  platform  component,  a  thinker  component,  and  a  sensor 
component.  These  components  represent  core  functionality  common  to  all  nodes.  The 
communication  component  represents  common  communications  functions  of  the  node  and 
includes  interfaces  and  Application  Program  Interfaces  (APIs)  for  real  or  virtual  communication 
via  network  (LAN/Intranet),  landline,  Joint  Data  Network,  and  many  other  protocols.  The 
platform  component  contains  common  interfaces  and  APIs  for  movement,  launching,  signature 
generation,  etc.  The  thinker  component  represents  interface  and  APIs  for  any  intelligent 
processes  that  are  required  by  the  node.  This  includes  real  or  simulated  human 
interaction/behavior  as  well  as  intelligent  agents  within  the  node.  The  sense  component 
represents  common  interfaces  and  APIs  for  sensor  functionality. 

The  diagram  also  shows  interfaces  for  common  simulation  services  provided  by 
ADASIM,  or  pass-through  service  provided  from  other  OASIS  federates  through  ADASIM. 
These  common  services  include:  simulation  setup,  maps,  terrain,  weather,  friendly/threat  unit 
management,  post-simulation  analysis,  data  collection,  and  real  networking. 

The  actual  SV-1  is  omitted  from  this  document  due  to  its  size.  The  actual  SV-1  can  be 
obtained  through  the  Operations  Research  Center  of  Excellence  or  via  the  Internet  at 
httn://www.orcen.usma.edu/adasim/index.asp. 
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Appendix  I :  SV-6  (System  Information  Exchange  Requirements  Matrix). 


The  System/Service  Information  Exchange  Requirements  Matrix  details  the  low  level  messages 
that  occur  between  nodes.  Each  of  these  corresponds  to  one  or  more  node-node  interactions 
listed  in  the  OV-6c.  (Appendix  G)  Additionally,  each  message  corresponds  to  a  high-level 
information  exchange  requirement  listed  in  the  OV-3  (Appendix  E). 

The  actual  SV-6  is  omitted  from  this  document  due  to  its  size.  The  actual  SV-6  can  be  obtained 
through  the  Operations  Research  Center  of  Excellence  or  via  the  Internet  at 
http://www.orcen.usma.edu/adasim/index.asp 
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